User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050206 Minefield/3.0pre Build Identifier: Thunderbird version 3.0a1pre (2008050303) You need to have folder with cyrillic letters in it. If you use Gmail on cyrillic language, it is there by default, like: Сва пошта. Then you need to uncheck to check new messages on startup for this account. In that case, on starting Thunderbird this folder is labeled &BC... pretty long nonsense string. After Thunderbird refreshes IMAP Account (like after clicking on it), everything is updated and fine. Reproducible: Always Steps to Reproduce: 1. 2. 3.

Similar phenomenon can be observed on INBOX & Inbox with Gmail IMAP, with trunk. (0) Label of Gmail Web : Inbox (1) msf file name under ImapMail directory : INBOX.msf (2) folder name in Subscribe : INBOX (3) folder name in folder pane : INBOX (after restart of Tb) (4) folder name in folder pane : Inbox (after folder click==open) When Tb 2.0.0.14, (1)/(2)/(4) is same, but folder name is displayed as "Inbox" even after restart, at (3). "&BC... pretty long nonsense string" is probably file name for msf. Check Properties/General Information/Location of the folder.

Confirmed with Tb trunk 2008/5/02 build on MS Win/XP SP2, with Japanese lable name of Gmail Web(==folder name of Gmail IMAP). - labels : Mbox/abc_1, Mbox/abc_2, ... Mbox/<Japanese_label_name> (subfolder of abc_1, abc_2, ... <Japanese_label_name> under Mbox folder) - After restart of Tb, file name for <Japanese_label_name> is displayed. (looks to be modified UTF-7 defined in RFC 3501 ) ( http://www.faqs.org/rfcs/rfc3501.html ) ( 5.1.3. Mailbox International Naming Convention ) - When other mail box such as abc_1 under Mbox is clicked, <Japanese_label_name> is displayed properly.

I don't think Gmail IMAP unique issue, but set dependency to meta Bug 402793 for ease of tracking.

> "&BC... pretty long nonsense string" is probably file name for msf. > Check Properties/General Information/Location of the folder. Yes, it is the name of the folder

I used Tb trunk(Version=3.0a2pre,BuildID=2008052203. Bug 434920 has been fixed) today for fix verification test of other bug, using same profile used by test in Comment #2. After it, I couln't reproduce this bug's problem anymore, with Gmail Imap, Japanese mail folder name, using same profile, even with old Tb trunk 2008/5/02 build. To Ivan Icin(bug opener): Ca you re-produce problem with latest Tb trunk nightly?

Well, I can see it for a split of second, but it doesn't require user action to get normal names, so I guess it is OK.

Problem still remains, and regression range was discovered by Bug 450754. Closing as DUP of Bug 450754, for ease of follow-up.